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Abstract 


This document specifies the Time Zone Information Format (TZif) for 
representing and exchanging time zone information, independent of any 
particular service or protocol. Two media types for this format are 
also defined. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8536. 


Copyright Notice 


Copyright (c) 2019 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(https://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Olson, et al. Standards Track [Page 1] 


RFC 8536 TZif February 2019 


Table of Contents 


Hn 


Introduction 
Conventions Used in This osent 
3 The Time Zone Information Format (TZif) 
.1l. TZif Header 
.2. TZif Data Block 
3.3. TZif Footer E 
3.3.1. TZ String Extensions 
4. Interoperability Considerations 
5. Use with the Time Zone Data Distribütion Service 
5.1. Truncating TZif Files 
5.2. Example TZDIST Request for TZif Data. 
6. Security Considerations 
7. Privacy Considerations 
8. IANA Considerations 
8.1. application/tzif 
8.2. application/tzif-leap 
9. References ax 
9.1. Normative Reed 
9.2. Informative References 
Appendix A. Common Tnperopetability. fsgusė 
Appendix B. Example TZif Files Sv Be wies wies ee do 
B.1. Version 1 File Representing UTC (with Leap Seconds) 
B.2. Version 2 File Representing Pacific/Honolulu : 
B.3. Truncated Version 3 File Representing Asia/Jerusalem 
Acknowledgments 
Authors’ Addresses 


N 


w w 


à 
XO «0 00 I I I -1 O1 O1 4» CO C0 PO 00 OY WW CO 


C) CO CO POP. PO PO N + 
a0) © Æ © H © 


Olson, et al. Standards Track [Page 2] 


RFC 8536 TZif February 2019 


Ly 


Introduction 


Time zone data typically consists of offsets from universal time 
(UT), daylight saving transition rules, one or more local time 


designations (acronyms or abbreviations), and optional leap-second 
adjustments. One such format for conveying this information is 
iCalendar [RFC5545]. It is a text-based format used by calendaring 


and scheduling systems. 


This document specifies the widely deployed Time Zone Information 
Format (TZif). It is a binary format used by most UNIX systems to 
calculate local time. This format was introduced in the 1980s and 
has evolved since then into multiple upward-compatible versions. 
There is a wide variety of interoperable software capable of 
generating and reading files in this format [tz-link]. 


This specification does not define the source of the data assembled 
into a TZif file. One such source is the IANA-hosted time zone 
database [RFC6557]. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


The following terms are used in this document (see "Sources for Time 
Zone and Daylight Saving Time Data" [tz-link] for more detailed 
information about civil timekeeping data and practice): 


Coordinated Universal Time (UTC): The basis for civil time since 
1960. It is approximately equal to mean solar time at the prime 
meridian (0 degrees longitude). 


Daylight Saving Time (DST): The time according to a location's law 
or practice, when adjusted as necessary from standard time. The 
adjustment may be positive or negative, and the amount of 
adjustment may vary depending on the date and time; the TZif 
format even allows the adjustment to be zero, although this is not 
common practice. 


International Atomic Time (TAI): The time standard based on atomic 
clocks since 1972. It is equal to UTC but without leap-second 
adjustments. 
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Leap-Second Correction (LEAPCORR): The value of TAI - UTC - 10 for 
timestamps after the first leap second, and zero for timestamps 
before that. The expression "TAI - UTC - 10" comes from the fact 
that TAI - UTC was defined to be 10 just prior to the first leap 
Second in 1972, so clocks with leap seconds have a zero LEAPCORR 
before the first leap second. 


Local Time: Civil time for a particular location. Its offset from 
universal time can depend on the date and time of day. 


POSIX Epoch: 1970-01-01 00:00:00 UTC, the basis for absolute 
timestamps in this document. 


Standard Time: The time according to a location's law or practice, 
unadjusted for Daylight Saving Time. 


Time Change: A change to civil timekeeping practice. It occurs when 
one or more of the following happen simultaneously: 


1. a change in UT offset 


2. a change in whether daylight saving time is in effect 


3. a change in time zone abbreviation 
4. a leap second (i.e., a change in LEAPCORR) 


Time Zone Data: The Time Zone Data Distribution Service (TZDIST) 
[RFC7808] defines "Time zone data" as "data that defines a single 
time zone, including an identifier, UTC offset values, DST rules, 
and other information such as time zone abbreviations." The 
interchange format defined in this document is one such form of 
time zone data. 


Transition Time: The moment of occurrence of a time change that is 
not a leap second. It is identified with a signed integer count 
of UNIX leap time seconds since the POSIX epoch. 


Universal Time (UT): The basis of civil time. This is the principal 
form of the mean solar time at the prime meridian (0 degrees 
longitude) for timestamps before UTC was introduced in 1960 and is 
UTC for timestamps thereafter. Although UT is sometimes called 
"UTC" or "GMT" in other sources, this specification uses the term 
"UT" to avoid confusion with UTC or with GMT. 
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UNIX Time: The time as returned by the time() function provided by 
the C programming language (see Section 3 of the "System 
Interfaces" volume of [POSIX]). This is an integer number of 


Seconds since the POSIX epoch, not counting leap seconds. As an 
extension to POSIX, negative values represent times before the 
POSIX epoch, using UT. 


UNIX Leap Time: UNIX time plus all preceding leap-second 
corrections. For example, if the first leap-second record in a 
TZif file occurs at 1972-06-30 23:59:60 UTC, the UNIX leap time 
for the timestamp 1972-07-01 00:00:00 UTC would be 78796801, one 
greater than the UNIX time for the same timestamp. Similarly, if 
the second leap-second record occurs at 1972-12-31 23:59:60 UTC, 
it accounts for the first leap second, so the UNIX leap time of 
1972-12-31 23:59:60 UTC would be 94694401, and the UNIX leap time 
of 1973-01-01 00:00:00 UTC would be 94694402. If a Tzif file 
specifies no leap-second records, UNIX leap time is equal to UNIX 
time. 


Wall Time: Another name for local time; short for "wall-clock time". 
3. The Time Zone Information Format (TZif) 


The Time Zone Information Format begins with a fixed 44-octet version 
1 header (Section 3.1) containing a field that specifies the version 
of the file's format. Readers designed for version N can read 
version N+1 files without too much trouble; data specific to version 
N+1 either appears after version N data so that earlier-version 
readers can easily ignore later-version data they are not designed 
for, or it appears as a minor extension to version N that version N 
readers are likely to tolerate well. 


The version 1 header is followed by a variable-length version 1 data 
block (Section 3.2) containing four-octet (32-bit) transition times 
and leap-second occurrences. These 32-bit values are limited to 
representing time changes from 1901-12-13 20:45:52 through 2038-01-19 
03:14:07 UT, and the version 1 header and data block are present only 
for backward compatibility with obsolescent readers, as discussed in 
Common Interoperability Issues (Appendix A). 


Version 1 files terminate after the version 1 data block. Files from 
versions 2 and 3 extend the format by appending a second 44-octet 
version 2+ header, a variable-length version 2+ data block containing 
eight-octet (64-bit) transition times and leap-second occurrences, 


and a variable-length footer (Section 3.3). These 64-bit values can 
represent times approximately 292 billion years into the past or 
future. 
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NOTE: All multi-octet integer values MUST be stored in network octet 

order format (high-order octet first, otherwise known as big-endian), 
with all bits significant. Signed integer values MUST be represented 
using two's complement. 


A TZif file is structured as follows: 


Version 1 Versions 2 & 3 
4------------- + D 7-5-7777 + 
| Version 1 | Version 1 
| | Header | Header 
4------------- + | cara mac oranda + 
| Version 1 | Version 1 
| Data Block | Data Block 
dcc EE * 4------------- + 

Version 2+ 
Header 
4------------- + 
Version 2+ 
Data Block 
Passe + 
Footer 
— retena + 


General Format of TZif Files 


3.1. TZif Header 


A TZif header is structured as follows (the lengths of multi-octet 
fields are shown in parentheses): 


4---------------— +---+ 
magic (4) ver | 
4+--------------- 4+---+4--------------------------------------- + 
[unused - reserved for future use] (15) 
4+--------------- 4+--------------- 4+--------------- 4+----------- + 
isutcnt (4) isstdent (4) | leapent (4) | 
4+--------------- 4+--------------- 4+--------------- + 
timecnt (4) typecnt (4) | charent (4) | 
4+--------------- 4+--------------- 4+--------------- + 


TZif Header 
The fields of the header are defined as follows: 
magic: The four-octet ASCII [RFC20] sequence "TZif" (0x54 0x5A 0x69 


0x66), which identifies the file as utilizing the Time Zone 
Information Format. 
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ver(sion): An octet identifying the version of the file's format. 
The value MUST be one of the following: 


NUL (0x00) Version 1 - The file contains only the version 1 
header and data block. Version 1 files MUST NOT contain a 
version 2+ header, data block, or footer. 


'2' (0x32) Version 2 - The file MUST contain the version 1 header 
and data block, a version 2+ header and data block, and a 
footer. The TZ string in the footer (Section 3.3), if 
nonempty, MUST strictly adhere to the requirements for the TZ 
environment variable as defined in Section 8.3 of the "Base 
Definitions" volume of [POSIX] and MUST encode the POSIX 
portable character set as ASCII. 


'3' (0x33) Version 3 - The file MUST contain the version 1 header 
and data block, a version 2+ header and data block, and a 
footer. The TZ string in the footer (Section 3.3), if 
nonempty, MUST conform to POSIX requirements with ASCII 
encoding, except that it MAY use the TZ string extensions 
described below (Section 3.3.1). 


isutcnt: A four-octet unsigned integer specifying the number of UT/ 
local indicators contained in the data block -- MUST either be 
zero or equal to "typecnt". 


isstdcnt: A four-octet unsigned integer specifying the number of 
standard/wall indicators contained in the data block -- MUST 
either be zero or equal to "typecnt". 


leapcnt: A four-octet unsigned integer specifying the number of 
leap-second records contained in the data block. 


timecnt: A four-octet unsigned integer specifying the number of 
transition times contained in the data block. 


typecnt: A four-octet unsigned integer specifying the number of 
local time type records contained in the data block -- MUST NOT be 
zero. (Although local time type records convey no useful 
information in files that have nonempty TZ strings but no 
transitions, at least one such record is nevertheless required 
because many TZif readers reject files that have zero time types.) 


charcnt: A four-octet unsigned integer specifying the total number 
of octets used by the set of time zone designations contained in 
the data block - MUST NOT be zero. The count includes the 
trailing NUL (0x00) octet at the end of the last time zone 
designation. 
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Although the version 1 and 2+ headers have the same format, magic 


number, and version fields, their 


count fields may differ, because 


the version 1 data can be a subset of the version 2+ data. 


3.2. TZif Data Block 


A TZif data block consists of seven variable-length elements, each of 
which is a series of items. The number of items in each series is 
determined by the corresponding count field in the header. The total 
length of each element is calculated by multiplying the number of 
items by the size of each item. Therefore, implementations that do 
not wish to parse or use the version 1 data block can calculate its 
total length and skip directly to the header of the version 2+ data 


block. 


In the version 1 data block, time values are 32 bits (TIME SIZE = 4 
octets). In the version 2+ data block, present only in version 2 and 
3 files, time values are 64 bits (TIME SIZE = 8 octets). 


The data block is structured as follows (the lengths of multi-octet 


fields are shown in parentheses): 


4--------------------------------------------------------- t 
transition times (timecnt x TIME SIZE) 
4--------------------------------------------------------- + 
transition types (timecnt) 
4--------------------------------------------------------- + 
local time type records (typecnt x 6) 
4--------------------------------------------------------- t 
time zone designations (charcnt) 
4--------------------------------------------------------- t 
leap-second records (leapcnt x (TIME SIZE + 4)) 
4--------------------------------------------------------- t 
standard/wall indicators (isstdcnt) 
4--------------------------------------------------------- + 
UT/local indicators (isutcnt) 
D —— + 


TZif Data Block 


The elements of the data block are 


defined as follows: 


transition times: A series of four- or eight-octet UNIX leap-time 
values sorted in strictly ascending order. Each value is used as 
a transition time at which the rules for computing local time may 
change. The number of time values is specified by the "timecnt" 


field in the header. Each time 


value SHOULD be at least -2**59, 
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(-2**59 is the greatest negated power of 2 that predates the Big 
Bang, and avoiding earlier timestamps works around known TZif 
reader bugs relating to outlandishly negative timestamps.) 


transition types: A series of one-octet unsigned integers specifying 
the type of local time of the corresponding transition time. 
These values serve as zero-based indices into the array of local 


time type records. The number of type indices is specified by the 
"timecnt" field in the header. Each type index MUST be in the 
range [0, "typecnt" - 1]. 


local time type records: A series of six-octet records specifying a 
local time type. The number of records is specified by the 
"Lypecnt" field in the header. Each record has the following 
format (the lengths of multi-octet fields are shown in 


parentheses): 

4--------------- 4+---+---+ 
| utoff (4) |dst | idx | 
4--------------- 4+---+---+ 


utoff: A four-octet signed integer specifying the number of 
seconds to be added to UT in order to determine local time. 
The value MUST NOT be -2**31 and SHOULD be in the range 
[-89999, 93599] (i.e., its value SHOULD be more than -25 hours 
and less than 26 hours). Avoiding -2**31 allows 32-bit clients 
to negate the value without overflow. Restricting it to 
[-89999, 93599] allows easy support by implementations that 
already support the POSIX-required range [-24:59:59, 25:59:59]. 


(is)dst: A one-octet value indicating whether local time should 
be considered Daylight Saving Time (DST). The value MUST be 0 
or 1. A value of one (1) indicates that this type of time is 
DST. A value of zero (0) indicates that this time type is 
standard time. 


(desig)idx: A one-octet unsigned integer specifying a zero-based 
index into the series of time zone designation octets, thereby 
selecting a particular designation string. Each index MUST be 


in the range [0, "charcnt" - 1]; it designates the 
NUL-terminated string of octets starting at position "idx" in 
the time zone designations. (This string MAY be empty.) A NUL 


octet MUST exist in the time zone designations at or after 
position "idx". 
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time zone designations: A series of octets constituting an array of 


NUL-terminated (0x00) time zone designation strings. The total 
number of octets is specified by the "charcnt" field in the 
header. Note that two designations MAY overlap if one is a suffix 
of the other. The character encoding of time zone designation 
strings is not specified; however, see Section 4 of this document. 


leap-second records: A series of eight- or twelve-octet records 


Specifying the corrections that need to be applied to UTC in order 
to determine TAI. The records are sorted by the occurrence time 
in strictly ascending order. The number of records is specified 
by the "leapcnt" field in the header. Each record has one of the 
following structures (the lengths of multi-octet fields are shown 
in parentheses): 


Version 1 Data Block: 


4--------------- 4--------------- 4--------------- + 
| occur (8) | corr (4) | 
4--------------- 4--------------- 4--------------- + 
occur (rence): A four- or eight-octet UNIX leap time value 


specifying the time at which a leap-second correction occurs. 
The first value, if present, MUST be nonnegative, and each 
later value MUST be at least 2419199 greater than the previous 
value. (This is 28 days’ worth of seconds, minus a potential 
negative leap second.) 


corr(ection): A four-octet signed integer specifying the value of 
LEAPCORR on or after the occurrence. The correction value in 
the first leap-second record, if present, MUST be either one 
(1) or minus one (-1). The correction values in adjacent leap- 
second records MUST differ by exactly one (1). The value of 
LEAPCORR is zero for timestamps that occur before the 
occurrence time in the first leap-second record (or for all 
timestamps if there are no leap-second records). 


standard/wall indicators: A series of one-octet values indicating 


Olson, 


whether the transition times associated with local time types were 
Specified as standard time or wall-clock time. Each value MUST be 
0 or 1. A value of one (1) indicates standard time. The valu 
MUST be set to one (1) if the corresponding UT/local indicator is 
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set to one (1). A value of zero (0) indicates wall time. The 
number of values is specified by the "isstdcnt" field in the 
header. If "isstdcnt" is zero (0), all transition times 


associated with local time types are assumed to be specified as 
wall time. 


UT/local indicators: A series of one-octet values indicating whether 
the transition times associated with local time types were 
Specified as UT or local time. Each value MUST be 0 or 1. A 
value of one (1) indicates UT, and the corresponding standard/wall 


indicator MUST also be set to one (1). A value of zero (0) 
indicates local time. The number of values is specified by the 
"isutcnt" field in the header. If "isutcnt" is zero (0), all 


transition times associated with local time types are assumed to 
be specified as local time. 


The type corresponding to a transition time specifies local time for 
timestamps starting at the given transition time and continuing up 
to, but not including, the next transition time. Local time for 
timestamps before the first transition is specified by the first time 
type (time type 0). Local time for timestamps on or after the last 
transition is specified by the TZ string in the footer (Section 3.3) 
if present and nonempty; otherwise, it is unspecified. If there are 
no transitions, local time for all timestamps is specified by the TZ 
String in the footer if present and nonempty; otherwise, it is 
Specified by time type 0. 


A given pair of standard/wall and UT/local indicators is used to 
designate whether the corresponding transition time was specified as 
UT, standard time, or wall-clock time. Note that there are only 
three combinations of the two indicators, given that the standard/ 
wall value MUST be one (1) if the UT/local value is one (1). This 
information can be useful if the transition times in a TZif file need 
to be transformed into transitions appropriate for another time zone 
(e.g. when calculating transition times for a simple POSIX TZ string 
such as "AKST9AKDT"). 


In order to eliminate unused space in a TZif file, every nonzero 
local time type index SHOULD appear at least once in the transition 
type array. Likewise, every octet in the time zone designations 
array SHOULD be used by at least one time type record. 
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TZif Footer 


TZif footer is structured as follows (the lengths of multi-octet 


lds are shown in parentheses): 
4---—4-------------------- +---+ 
| NL| TZ string (0...) [NL | 
4---—4-------------------- +---+ 


TZif Footer 


elements of the footer are defined as follows: 


An ASCII new line character (0x0A). 


string: A rule for computing local time changes after the last 
transition time stored in the version 2+ data block. The string 
is either empty or uses the expanded format of the "TZ" 
environment variable as defined in Section 8.3 of the "Base 
Definitions" volume of [POSIX] with ASCII encoding, possibly 
utilizing extensions described below (Section 3.3.1) in version 3 
files. If the string is empty, the corresponding information is 
not available. If the string is nonempty and one or more 
transitions appear in the version 2+ data, the string MUST be 
consistent with the last version 2+ transition. In other words, 
evaluating the TZ string at the time of the last transition should 
yield the same time type as was specified in the last transition. 
The string MUST NOT contain NUL octets or be NUL-terminated, and 
it SHOULD NOT begin with the ':' (colon) character. 


The TZif footer is present only in version 2 and 3 files, as the 
obsolescent version 1 format was designed before the need for a 
footer was apparent. 


Olson, 
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TZ String Extensions 


The TZ string in a version 3 TZif file MAY use the following 
extensions to POSIX TZ strings. These extensions are described using 
the terminology of Section 8.3 of the "Base Definitions" volume of 
[POSIX]. 


[9] 


The hours part of the transition times may be signed and range 
from -167 through 167 (-167 <= hh <= 167) instead of the POSIX- 
required unsigned values from 0 through 24. 


Example: <-03>3<-02>,M3.5.0/-2,M10.5.0/-1 
This represents a time zone that observes daylight saving time 
from 22:00 on the day before March's last Sunday until 23:00 on 
the day before October's last Sunday. Standard time is 3 hours 
west of UT and is abbreviated "-03"; daylight saving time is 2 
hours west of UT and is abbreviated "-02". 


DST is considered to be in effect all year if it starts January 1 
at 00:00 and ends December 31 at 24:00 plus the difference between 
daylight saving and standard time, leaving no room for standard 
time in the calendar. 


Example: EST5EDT,0/0,4J365/25 
This represents a time zone that observes daylight saving time 
all year. It is 4 hours west of UT and is abbreviated "EDT". 


4. Interoperability Considerations 


The following practices help ensure the interoperability of TZif 
applications. 


[9] 


Olson, 


Version 1 files are considered a legacy format and SHOULD NOT be 
generated, as they do not support transition times after the year 
2038. 


Implementations that only understand version 1 MUST ignore any 
data that extends beyond the calculated end of the version 1 data 
block. 


Implementations SHOULD generate a version 3 file if TZ string 
extensions are necessary to accurately model transition times. 
Otherwise, version 2 files SHOULD be generated. 


The sequence of time changes defined by the version 1 header and 
data block SHOULD be a contiguous sub-sequence of the time changes 
defined by the version 2+ header and data block, and by the 
footer. This guideline helps obsolescent version 1 readers agree 
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with current readers about timestamps within the contiguous sub- 
sequence. It also lets writers not supporting obsolescent readers 
use a "timecnt" of zero in the version 1 data block to save space. 


o Time zone designations SHOULD consist of at least three (3) and no 
more than six (6) ASCII characters from the set of alphanumerics, 
'-', and ‘+’. This is for compatibility with POSIX requirements 
for time zone abbreviations. 


o When reading a version 2 or 3 file, implementations SHOULD ignore 
the version 1 header and data block except for the purpose of 
Skipping over them. 


o Implementations SHOULD calculate the total lengths of the headers 
and data blocks and check that they all fit within the actual file 
Size, as part of a validity check for the file. 


o When a TZif file is used in a MIME message entity, it SHOULD be 
indicated by one of the following media types: 


* "application/tzif-leap" (Section 8.2) to indicate that leap- 
Second records are included in the TZif data as necessary (none 
are necessary if the file is truncated to a range that precedes 
the first leap second). 


* "application/tzif" (Section 8.1) to indicate that leap-second 
records are not included in the TZif data; "leapcnt" in the 
header(s) MUST be zero (0). 


o Common interoperability issues and possible workarounds are 
described in Appendix A. 


5. Use with the Time Zone Data Distribution Service 


The Time Zone Data Distribution Service (TZDIST) [RFC7808] is a 
service that allows reliable, secure, and fast delivery of time zone 
data and leap-second rules to client systems such as calendaring and 
Scheduling applications or operating systems. 


A TZDIST service MAY supply time zone data to clients in the Time 
Zone Information Format. Such a service MUST indicate that it 
supports this format by including the media type "application/tzif" 
(Section 8.1) in its "capabilities" response (see Section 5.1 of 
[RFC7808]). A TZDIST service MAY also include the media type 
"application/tzif-leap" (Section 8.2) in its "capabilities" response 
if it is able to generate TZif files containing leap-second records. 
A TZDIST service MUST NOT advertise the "application/tzif-leap" media 
type without also advertising "application/tzif". 
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TZDIST clients MUST use the HTTP "Accept" [RFC7231] header field to 
indicate their preference to receive data in the "application/tzif" 
and/or "application/tzif-leap" formats. 


5.1.  Truncating TZif Files 


As described in Section 3.9 of [RFC7808], a TZDIST service MAY 
truncate time zone transition data. A truncated TZif file is valid 
from its first and up to, but not including, its last version 2+ 
transition time, if present. 


When truncating the start of a TZif file, the service MUST supply in 
the version 2+ data a first transition time that is the start point 
of the truncation range. As with untruncated TZif files, time type 0 
indicates local time immediately before the start point, and the time 
type of the first transition indicates local time thereafter. 


When truncating the end of a TZif file, the service MUST supply in 
the version 2+ data a last transition time that is the end point of 
the truncation range and MUST supply an empty TZ string. As with 
untruncated TZif files with empty TZ strings, a truncated TZif file 
does not indicate local time after the last transition. 


All represented information that falls inside the truncation range 
MUST be the same as that represented by a corresponding untruncated 
TZif file. 


TZDIST clients SHOULD NOT use a truncated TZif file (as described 
above) to interpret timestamps outside the truncation time range. 


5.2. Example TZDIST Request for TZif Data 


In this example, the client checks the server for the available 
formats and then requests that the time zone with a specific time 
zone identifier be returned in Time Zone Information Format. 
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Note that this example presumes that the time zone context path has 
been discovered (see [RFC7808], Section 4.2.1) to be "/tzdist". 


>> Request << 


GET /tzdist/capabilities HTTP/1.1 
Host: tz.example.com 


>> Response << 


HTTP/1.1 200 OK 

Date: Fri, 01 Jun 2018 14:52:23 GMT 
Content-Type: application/json; charset="utf-8" 
Content-Length: xxxx 


{ 


"version": 1, 


"infos -{ 
"primary-source": "IANA:2018e", 
"formats": [ 
"text/calendar", 
"application/tzif", 
"application/tzif-leap" 
l, 


}, 


>> Request << 


GET /tzdist/zones/America$2FNew York HTTP/1.1 
Host: tz.example.com 
Accept: application/tzif 


>> Response << 


HTTP/1.1 200 OK 

Date: Fri, 01 Jun 2018 14:52:24 GMT 
Content-Type: application/tzif 
Content-Length: xxxx 

ETag: "123456789-000-111" 


TZif2...[binary data without leap-second records]... 
EST5EDT,M3.2.0,M11.1.0 
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6. 


8. 


Security Considerations 


The Time Zone Information Format contains no executable code, and it 
does not define any extensible areas that could be used to store such 
code. 


TZif contains counted arrays of data elements. All counts should be 
checked when processing TZif objects, to guard against references 
past the end of the object. 


TZif provides no confidentiality or integrity protection. Time zone 
information is normally public and does not call for confidentiality 
protection. Since time zone information is used in many critical 
applications, integrity protection may be required and must be 
provided externally. 


Privacy Considerations 


The Time Zone Information Format contains publicly available data, 
and it does not define any extensible areas that could be used to 
store private data. 


As discussed in Section 9 of [RFC7808], transmission of time zone 
data over an insecure communications channel could leak the past, 
current, or future location of a device or user. As such, TZif data 
transmitted over a public communications channel MUST be protected 
with a confidentiality layer such as that provided by Transport Layer 
Security (TLS) [RFC8446]. 


IANA Considerations 


This document defines two media types [RFC6838] for the exchange of 
data utilizing the Time Zone Information Format. 


1. application/tzif 

Type name: application 

Subtype name:  tzif 

Required parameters: none 
Optional parameters: none 
Encoding considerations: binary 


Security considerations: See Section 6 of RFC 8536. 
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Interoperability considerations: See Section 4 of RFC 8536. 


Published specification: This specification. 


Applications that use this media type: This media type is designed 
for widespread use by applications that need to use or exchange 
time zone information, such as the Time Zone Information Compiler 
(zic) [ZIC] and the GNU C Library [GNU-C]. The Time Zone 
Distribution Service [RFC7808] can directly use this media type. 


Fragment identifier considerations: N/A 


Additional information: 


Magic number(s): The first 4 octets are 0x54, Ox5A, 0x69, 0x66 
File extensions(s): N/A 
Macintosh file type code(s): N/A 


Person & email address to contact for further information: 
Time Zone Database mailing list <tz@iana.org> 


Intended usage: COMMON 

Restrictions on usage: N/A 

Author: See the "Authors' Addresses" section of RFC 8536. 
Change controller:  IETF 


8.2. application/tzif-leap 


Type name: application 


Subtype name:  tzif-leap 


Required parameters: none 

Optional parameters: none 

Encoding considerations: binary 

Security considerations: See Section 6 of RFC 8536. 
Interoperability considerations: See Section 4 of RFC 8536. 


Published specification: This specification. 
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Applications that use this media type: This media type is designed 
for widespread use by applications that need to use or exchange 
time zone information, such as the Time Zone Information Compiler 
(zic) [ZIC] and the GNU C Library [GNU-C]. The Time Zone 
Distribution Service [RFC7808] can directly use this media type. 


Fragment identifier considerations: N/A 


Additional information: 


Magic number(s): The first 4 octets are 0x54, Ox5A, 0x69, 0x66 
File extensions(s): N/A 
Macintosh file type code(s): N/A 


Person & email address to contact for further information: 
Time Zone Database mailing list <tz@iana.org> 


Intended usage: COMMON 
Restrictions on usage: N/A 
Author: See the "Authors' Addresses" section of RFC 8536. 
Change controller:  IETF 
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Appendix A. Common Interoperability Issues 


This section documents common problems in implementing this 
specification. Most of these are problems in generating TZif files 
for use by readers conforming to predecessors of this specification 
[EGGERT-TZ]. The goals of this section are: 


1. to help TZif writers output files that avoid common pitfalls in 
older or buggy TZif readers, 


2. to help TZif readers avoid common pitfalls when reading files 
generated by future TZif writers, and 


3. to help any future specification authors see what sort of 
problems arise when the TZif format is changed. 


When new versions of the TZif format have been defined, a design goal 
has been that a reader can successfully use a TZif file even if the 
file is of a later TZif version than what the reader was designed 
for. When complete compatibility was not achieved, an attempt was 
made to limit glitches to rarely used timestamps and allow simple 
partial workarounds in writers designed to generate new-version data 
useful even for older-version readers. This section attempts to 
document these compatibility issues and workarounds, as well as 
documenting other common bugs in readers. 


Interoperability problems with TZif include the following: 


O Some readers examine only version 1 data. As a partial 
workaround, a writer can output as much version 1 data as 
possible. However, a reader should ignore version 1 data and use 
version 2+ data, even if the reader's native timestamps have only 
32 bits. 


o Some readers designed for version 2 might mishandle timestamps 
after a version 3 file's last transition, because they cannot 
parse extensions to POSIX in the TZ-like string. As a partial 
workaround, a writer can output more transitions than necessary, 
So that only far-future timestamps are mishandled by version 2 
readers. 


O Some readers designed for version 2 do not support permanent 
daylight saving time -- e.g., a TZ string "ESTSEDT,0/0,J365/25" 
denoting permanent Eastern Daylight Time (-04). As a partial 
workaround, a writer can substitute standard time for the next 
time zone east -- e.g., "ASTA" for permanent Atlantic Standard 
Time (-04). 
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Olson, 


Some readers ignore the footer and instead predict future 
timestamps from the time type of the last transition. As a 
partial workaround, a writer can output more transitions than 
necessary. 


Some readers do not use time type 0 for timestamps before the 
first transition, in that they infer a time type using a heuristic 
that does not always select time type 0. As a partial workaround, 
a writer can output a dummy (no-op) first transition at an early 
time. 


Some readers mishandle timestamps before the first transition that 
has a timestamp not less than -2**31. Readers that support only 
32-bit timestamps are likely to be more prone to this problem, for 
xample, when they process 64-bit transitions, only some of which 
are representable in 32 bits. As a partial workaround, a writer 
can output a dummy transition at timestamp -2**31. 


Some readers mishandle a transition if its timestamp has the 
minimum possible signed 64-bit value.  Timestamps less than -2**59 
are not recommended. 


Some readers mishandle POSIX-style TZ strings that contain "«" or 
">". As a partial workaround, a writer can avoid using '«' or '»' 
for time zone abbreviations containing only alphabetic characters. 


Many readers mishandle time zone abbreviations that contain non- 
ASCII characters. These characters are not recommended. 


Some readers may mishandle time zone abbreviations that contain 
fewer than 3 or more than 6 characters, or that contain ASCII 
characters other than alphanumerics, '-', and '*'. These 
abbreviations are not recommended. 


Some readers mishandle TZif files that specify daylight saving 
time UT offsets that are less than the UT offsets for the 
corresponding standard time. These readers do not support 
locations like Ireland, which uses the equivalent of the POSIX TZ 
string "IST-1GMTO,M10.5.0,M3.5.0/1", observing standard time (IST, 
+01) in summer and daylight saving time (GMT, +00) in winter. As 
a partial workaround, a writer can output data for the equivalent 
of the POSIX TZ string "GMTOIST,M3.5.0/1,M10.5.0", thus swapping 
Standard and daylight saving time. Although this workaround 
misidentifies which part of the year uses daylight saving time, it 
records UT offsets and time zone abbreviations correctly. 
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Some interoperability problems are reader bugs that are listed her 
mostly as warnings to developers of readers. 


[9] 


Some readers do not support negative timestamps. Developers of 
distributed applications should keep this in mind if they need to 
deal with pre-1970 data. 


Some readers mishandle timestamps before the first transition that 
has a nonnegative timestamp. Readers that do not support negative 
timestamps are likely to be more prone to this problem. 


Some readers mishandle time zone abbreviations like "-08" that 
contain "+", '—-', or digits. 


Some readers mishandle UT offsets that are out of the traditional 
range of -12 through +12 hours and so do not support locations 
like Kiritimati that are outside this range. 


Some readers mishandle UT offsets in the range [-3599, -1] seconds 
from UT, because they integer-divide the offset by 3600 to get 0 
and then display the hour part as "+00". 


Some readers mishandle UT offsets that are not a multiple of one 
hour, 15 minutes, or 1 minute. 


Appendix B. Example TZif Files 


The following sections contain annotated hexadecimal dumps of example 
TZif files. 


Note that these examples should only be considered informative. 
Although the example data entries are current as of the publication 
date of this document, the data will likely change in the future as 
leap seconds are added and changes are made to civil time. 


Olson, 
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B.1. Version 1 File Representing UTC (with Leap Seconds) 


+------- 4+--------------- 4+------------------ 4+------------------------ + 
File Data Octets Record Name / Field Value 
Offset (hexadecimal) Field Name 
4------- 4--------------- 4------------------ 4------------------------ * 
000 54 5a 69 66 magic "TZzif" 
004 00 version QO (1) 
005 00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 
020 00 00 00 01 isutccnt 1 
024 00 00 00 01 isstdcnt 1 
028 00 00 00 1b isleapcnt 27 
032 00 00 00 00 timecnt 0 
036 00 00 00 O1 typecnt 1 
040 00 00 00 04 charcnt 4 


localtimetype[0] 


044 00 00 00 00 utcoff 00:00 
048 00 isdst 0 (no) 
049 00 desigidx 0 

050 55 54 43 00 designations[0] "UTC 


leapsecond[0] 
054 04 b2 58 00 occurrence 78796800 
(1972-06-30T23:59:602) 
058 00 00 00 01 correction 1 


leapsecond[1] 
062 05 a4 ec 01 occurrence 94694401 
(1972-12-31T23:59:602) 
066 00 00 00 02 correction 2 


leapsecond[2] 
070 07 86 1f 82 occurrence 126230402 
(1973-12-31T23:59:602) 
074 00 00 00 03 correction 5 


leapsecond[3] 
078 09 67 53 03 occurrence 157766403 
(1974-12-31T23:59:602) 
082 00 00 00 04 correction 4 
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086 


090 


094 


098 


102 


106 


110 


114 


118 


122 


126 


130 


134 


138 


142 


146 


150 


154 


158 


Olson, et al. 


Ob 


00 


Od 


00 


Of 


00 


10 


00 


12 


00 


15 


00 


17 


00 


19 


00 


1d 


00 


21 


48 


00 


2b 


00 


Oc 


00 


ed 


00 


ce 


00 


9f 


00 


80 


00 


62 


00 


25 


00 


da 


86 


00 


0b 


00 


3f 


00 


72 


00 


a6 


00 


ca 


00 


fe 


00 


31 


00 


ea 


00 


e5 


84 


05 


85 


06 


06 


07 


87 


08 


08 


09 


89 


0a 


0a 


0b 


8b 


Oc 


Oc 


Od 


Od 


TZif 
leapsecond[4] 
occurrence 
correction 


leapsecond[5] 
occurrence 


correction 


leapsecond[6] 
occurrence 


correction 


leapsecond[7] 
occurrence 


correction 


leapsecond[8] 
occurrence 


correction 


leapsecond[9] 
occurrence 


correction 


leapsecond[10] 
occurrence 


correction 


leapsecond[11] 
occurrence 


correction 


leapsecond[12] 
occurrence 


correction 


leapsecond[13] 
occurrence 
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189302404 


(1975-12-31T23: 


5 


220924805 


(1976-12-31T23: 


6 


252460806 


(1977-12-31T23: 


7 


283996807 


(1978-12-31T23: 


8 


315532808 


(1979-12-31T23: 


9 


362793609 


(1981-06-30T23: 


10 


394329610 


(1982-06-30T23: 


11 


425865611 


(1983-06-30T23: 


12 


489024012 


(1985-06-30T23: 


13 


567993613 


(1987-12-31T23: 


59:3 


59: 


5:95 


59: 


59$ 


59$ 


59: 


59$ 


59$ 


593 
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602) 


602) 


602) 


602) 


602) 


602) 


602) 


602) 


602) 


602) 
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162 


166 


170 


174 


178 


182 


186 


190 


194 


198 


202 


206 


210 


214 


218 


222 


226 


230 


234 
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00 


25 


00 


27 


00 


2a 


00 


2c 


00 


2e 


00 


30 


00 


33 


00 


36 


00 


43 


00 


00 


9e 


00 


LE 


00 


50 


00 


32 


00 


13 


00 


e7 


00 


b8 


00 


8c 


00 


b7 


00 


00 


9d 


00 


di 


00 


£5 


00 


29 


00 


5c 


00 


24 


00 


48 


00 


10 


00 


1b 


00 


0e 


8e 


Of 


Of 


10 


90 


LT 


11 


12 


92 


13 


13 


14 


94 


15 


15 


16 


96 


17 


TZif 


correction 


leapsecond[14] 
occurrence 


correction 


leapsecond[15] 
occurrence 


correction 


leapsecond[16] 
occurrence 


correction 


leapsecond[17] 
occurrence 


correction 


leapsecond[18] 
occurrence 


correction 


leapsecond[19] 
occurrence 


correction 


leapsecond[20] 
occurrence 


correction 


leapsecond[21] 
occurrence 


correction 


leapsecond[22] 
occurrence 


correction 
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14 


631152014 


(1989-12-31T23: 


15 


662688015 


(1990-12-31T23: 


16 


709948816 


(1992-06-30T23: 


17 


741484817 


(1993-06-30T23: 


18 


773020818 


(1994-06-30T23: 


19 


820454419 


(1995-12-31T23: 


20 


867715220 


(1997-06-30T23: 


2 


915148821 


(1998-12-31T23: 


22 


1136073622 


(2005-12-31T23: 


23 


59: 


59:3 


593 


59: 


59:32 


59: 


59$ 


59:3 


59: 
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leapsecond[23] 


238 49 5c 07 97 occurrence 1230768023 
(2008-12-31T23:59:602) 
242 00. 00 00 18 correction 24 


leapsecond[24] 


246 4f ef 93 18 occurrence 1341100824 
(2012-06-30T23:59:602) 
250 00 00 00 19 correction 25 


leapsecond[25] 


254 55 93 2d 99 occurrence 1435708825 
(2015-06-30T23:59:602) 
258 00 00 00 1a correction 26 


leapsecond[26] 


262 58 68 46 9a occurrence 1483228826 
(2016-12-31T23:59:602) 

266 00 00 00 1b correction 27 

270 00 UT/local[0] 0 (local) 

271 00 standard/wall[0] 0 (wall) 

------- 4---------------4--------2------2----4------------------------X 


To determine TAI corresponding to 2000-01-01T00:00:007Z 


UNIX time = 946684800), the following procedure would be followed: 
Find the latest leap-second occurrence prior to the time of 
interest (leapsecond[21]) and note the correction value 


(LEAPCORR = 22). 


Add LEAPCORR + 10 to the time of interest to yield TAI of 
2000-01-01T00:00:32. 
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B.2. Version 2 File Representing Pacific/Honolulu 
T4-------- 4-------------- 4------------------ 4------------------------ t 
File Hexadecimal Record Name / Field Value 
Offset Octets Field Name 
T4-------- 4-------------- 4------------------ 4------------------------ t 
000 54 5a 69 66 magic TALE" 
004 32 version '2' (2) 
005 00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 
020 00 00 00 06 isutcent 6 
024 00 00 00 06 isstdcnt 6 
028 00 00 00 00 isleapcnt 0 
032 00 00 00 07 timecnt 7 
036 00 00 00 06 typecnt 6 
040 00 00 00 14 charcnt 20 
044 80 00 00 00 trans time[0 —2147483648 
(1901-12-13T20:45:527) 
048 bb 05 43 48 trans time[1 -1157283000 
(1933-04-30T12:30:002) 
052 bb 21 71 58 trans time[2 -1155436200 
(1933-05-21T21:30:002) 
056 cb 89 3d c8 trans time[3 -880198200 
(1942-02-09T12:30:002) 
060 d2 23 f4 70 trans time[4 -769395600 
(1945-08-14T23:00:002) 
064 d2 61 49 38 trans time[5 -765376200 
(1945-09-30T11:30:002) 
068 d5 8d 73 48 trans time[6 -712150200 
(1947-06-08T12:30:002) 
072 01 trans type[0 i 
073 02 trans typell 2 
074 01 trans type[2 1 
075 03 trans type[3 3 
076 04 trans type[4 4 
077 01 trans type[5 1 
078 05 trans type[6 5 
localtimetype[0] 
079 ff ff 6c 02 utcoff -37886 (-10:21:26) 
083 00 isdst 0 (no) 
084 00 desigidx 0 
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localtimetypel1] 


085 ff ff 6c 58 utcoff -37800 (-10:30) 

089 00 isdst 0 (no) 

090 04 desigidx 4 
localtimetype[2] 

091 ff ff 7a 68 utcoff —34200 (-09:30) 

095 01 isdst 1 (ves) 

096 08 desigidx 8 
localtimetype[3] 

097 ff ff 7a 68 utcoff —34200 (-09:30) 

101 01 isdst 1 (ves) 

102 Oc desigidx 12 
localtimetype[4] 

103 ff ff 7a 68 utcoff —34200 (-09:30) 

107 01 isdst 1 (ves) 

108 10 desigidx 16 
localtimetype[5] 

109 ff ff 73 60 utcoff -36000 (-10:00) 

113 00 isdst 0 (no) 

114 04 desigidx 4 

LITS 4c 4d 54 00 designations [0] "LMT" 

119 48 53 54 00 designations [4] "HST" 

123 48 44 54 00 designations[8] "HDT" 

127 48 57 54 00 designations [12] "HWT" 

131 48 50 54 00 designations[16] "HET" 

135 00 UT/local[0] 1 (UT) 

136 00 UT/local [1] 0 (local) 

137 00 UT/local [2] 0 (local) 

138 00 UT/local[3] 0 (local) 

139 01 UT/local[4] 1 (UT) 

140 00 UT/local[5] 0 (local) 

141 00 standard/wall[0] 1 (standard) 

142 00 standard/wall[1] 0 (wall) 

143 00 standard/wall[2] O0 (wall) 

144 00 standard/wall[3] 0 (wall) 

145 01 standard/wall[4] 1 (standard) 

146 00 standard/wall[5] O0 (wall) 

147 54 5a 69 66 magic MTALE" 

151 32 version '2' (2) 
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152 


167 
171 
175 
179 
183 
187 


191 


199 


207 


215 


223 


231 


239 


247 
248 
249 
250 
251 
252 
253 


254 
258 
259 


260 
264 
265 


266 
270 
271 
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00 
00 
00 
00 
00 
00 
00 
00 
00 
00 


ff 
74 
ff 
bb 
ff 
bb 
ff 
cb 
EE 
d2 
ff 
d2 
ff 
d5 


01 
02 
01 
03 
04 
01 
05 


ff 
00 
00 


tf 
00 
04 


ff 
01 
08 


00 00 00 
00 00 00 
00 00 00 
00 00 

00 00 06 
00 00 06 
00 00 00 
00 00 07 
00 00 06 
00 00 14 


ff ff ff 
e0 70 be 
ff ff ff 
05 43 48 
ff ff ff 
21 71 58 
ff. ff ff 
89 3d c8 
ff ff ff 
23 £4 70 
ff ff ff 
61 49 38 
ER “at ser 
8d 73 48 


ff 6c 02 


ff 6c 58 


ff 7a 68 


TZif 


isutccnt 
isstdcnt 
isleapcnt 
timecnt 
typecnt 
charcnt 
trans time[0 
trans time[1 
trans time[2 
trans time[3 


trans time[4 


trans time[5 


trans time[6 


trans type 
trans type 
trans type 
trans type 
trans type 
trans type 
trans type 


NUP © N° H © 


localtimetype[0] 
utcoff 

isdst 

desigidx 


localtimetype[1] 
utcoff 

isdst 

desigidx 


localtimetype[2] 
utcoff 

isdst 

desigidx 
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Doom 


0 


-2334101314 

1896-01-13T22:31 
1157283000 
1933-04-30T12:30: 


( :262) 
( 

-1155436200 

( 

( 


002) 


1933-05-21T21:30: 
880198200 
1942-02-09T12:30: 
-769395600 
(1945-08-14T23:00: 
-765376200 
(1945-09-30T11:30:002) 
-712150200 
(1947-06-08T12:30:002) 


002) 


002) 


002) 


O1 H 4 © HN H 


-37886 
0 (no) 
0 


(-10:21:26) 


-37800 
0 (no) 
4 


(-10:30) 


-34200 
1 (yes) 
8 


(-09:30) 
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localtimetype [3] 

272 ff ff 7a 68 utcoff -34200 (-09:30) 

276 01 isdst 1 (yes) 

277 Oc desigidx 12 
localtimetype [4] 

278 ff ff 7a 68 utcoff -34200 (-09:30) 

282 01 isdst 1 (ves) 

283 10 desigidx 16 
localtimetype[5] 

284 ff ff 73 60 utcoff -36000 (-10:00) 

288 00 isdst 0 (no) 

289 04 desigidx 4 

290 4c 4d 54 00 designations[0] "LMT" 

294 48 53 54 00 designations[4] "HST" 

298 48 44 54 00 designations[8] THDTT 

302 48 57 54 00 designations[12] "HWT" 

306 48 50 54 00 designations[16] "HPT" 

310 00 UT/local[0] 0 (local) 

311 00 UT/local [1] 0 (local) 

312 00 UT/local[2] 0 (local) 

313 00 UT/local[3] 0 (local) 

314 OT UT/local[4] 1 (UT) 

315 00 UT/local[5] 0 (local) 

316 00 standard/wall[0] 0 (wall) 

317 00 standard/wall[1] 0 (wall) 

318 00 standard/wall[2] 0 (wall) 

319 00 standard/wall[3] 0 (wall) 

320 01 standard/wall[4] 1 (standard) 

321 00 standard/wall[5] O0 (wall) 

322 0a NL "n^ 

323 48 53 54 31 TZ string "HST10" 

30 
328 0a NL "Nn 
4-------- 4-------------- 4------------------ 4------------------------ + 
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To determine the local time in this time zone corresponding to 
1933-05-04T12:00:00Z (UNIX time = -1156939200), the following 
procedure would be followed: 


1. Find the latest time transition prior to the time of interest 
(trans time[1]). 


2. Reference the corresponding transition type (trans type[1]) to 
determine the local time type index (2). 


3. Reference the corresponding local time type (localtimetype[2]) to 
determine the offset from UTC (-09:30), the daylight saving 
indicator (1 = yes), and the index into the time zone designation 
strings (8). 


4. Look up the corresponding time zone designation string 
(designations[8] = "HDT"). 


5. Add the UTC offset to the time of interest to yield a local 
daylight saving time of 1933-05-04T02:30:00-09:30 (HDT). 


To determine the local time in this time zone corresponding to 
2019-01-01T00:00:00Z (UNIX time = 1546300800), the following 
procedure would be followed: 


1. Find the latest time transition prior to the time of interest 
(there is no such transition). 


2. Look up the TZ string in the footer ("HST10"), which indicates 
that the time zone designation is "HST" year-round, and the 
offset to UTC is 10:00. 


3. Subtract the UTC offset from the time of interest to yield a 
standard local time of 2018-12-31T14:00:00-10:00 (HST). 
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Truncated Version 3 File Representing Asia/Jerusalem 


The following TZif file has been truncated to start on 


2038-01-01T00:00:002. 
+-------- 4-------------- 4------------------ 4------------------------ + 
File Hexadecimal Record Name / Field Value 
Offset Octets Field Name 
4-------- 4--------------4------------------ 
000 54 5a 69 66 magic VEALE" 
004 33 version ESP c3) 
005 00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 
020 00 00 00 00 isutcent 0 
024 00 00 00 00 isstdcnt 0 
028 00 00 00 00 isleapcnt 0 
032 00 00 00 00 timecnt 0 
036 00 00 00 00 typecnt 0 
040 00 00 00 00 charcnt 0 
044 54 5a 69 66 magic "PALE" 
048 33 version FSP (3) 
049 00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 
064 00 00 00 03 isutccnt E 
068 00 00 00 03 isstdcnt 1 
072 00 00 00 00 isleapcnt 0 
076 00 00 00 03 timecnt T 
080 00 00 00 03 typecnt 1 
084 00 00 00 08 charcnt 4 
088 00 00 00 00 trans time[0] 2145916800 
7f e8 17 80 
096 00 trans type[0] 0 
localtimetype[0] 
097 00 00 1c 20 utcoff 7200 (+02:00) 
TOT 00 isdst 0 (no) 
102 00 desigidx 0 
103 49 53 54 00 designations[0] "IST" 
107 01 UT/local[0] 1 (UT) 
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108 01 standard/wall[0] 1 (standard) 
109 0a NL r\n’ 
110 49 53 54 2d TZ string "IST-2IDT, 
32 49 44 54 M3.4.4/26,M10.5.0" 


31 30 2e 35 
2e 30 
136 0a NL "NT 
4-------- 4-------------- 4------------------ 4------------------------ t 
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